Debugging is a process of detecting and locating errors or events in computer programs and other software with a view to eliminate such errors or events. Debugging may also involve the step of eliminating such errors. The debugging process is implemented using a debugger, which is a computer program or programs for detecting, tracing, and eliminating errors or events in computer programs, and other software. The latter are each referred to hereinafter as the “debugee”.
A breakpoint is a point in a computer program or software where execution may be halted, normally at a place that is convenient for restarting execution of the program or software (i.e., the debugee) from that point. That is, breakpoints are events deliberately inserted or “planted” in a debugee by a debugger to receive control when the debugee reaches a certain point during execution of the debugee. At that point, the debugger needs access to the state of the debugee (perhaps with the ability to change that state), and either to resume or terminate execution of the debugee.
If a breakpoint is applicable only in the context of a specific process, the breakpoint is considered to be a local breakpoint. The same applies for plural breakpoints. Application debuggers generally use local breakpoints.
In contrast, global breakpoints are breakpoints active across all processes executing in a computer system, where two or more processes may use the same code segment. In other words, global breakpoints are applicable in all instances of a program or software code segment. If a global breakpoint event occurs, the debugger can instrument the debugged code irrespective of the process running that code. In this case, the concept of one debugee does not apply, and the target is not the process being debugged but the code that is being executed. Kernel-level debuggers and some code-instrumentation tools use global breakpoints, because the focus is on the code being debugged/instrumented and not on any specific process context.
Breakpoints are placed by a mechanism that enables the determination of whether a breakpoint condition is present at any time. Some common techniques for placing breakpoints are:                inserting a special instruction at breakpoint location,        inserting an illegal instruction at breakpoint location, and        using a special debug register at breakpoint location.        
Breakpoints are typically placed using a special breakpoint instruction available on most processor architectures.
Implementing breakpoints for debugging multi-threaded applications under multi-processing environments presents a number of problems and detecting zombie breakpoints is one of the most difficult.
The term “zombie breakpoint” appears in the context of a race condition between a breakpoint hit in one thread/processor and the simultaneous removal of the same breakpoint in the context of another thread/processor. By the time the breakpoint handler gets to process the breakpoint hit, the breakpoint has been removed without any trace by another thread/processor and is no longer “owned” by the debugger. This leads to a situation, where the breakpoint handler thinks that the breakpoint event happened due to some other external cause and incorrectly passes the breakpoint back to the operating system, which treats the breakpoint as an unhandled exception.
Thus, a need exists for an improved method of detecting zombie breakpoints.